Systems in which a payments processor uses a network to connect a large number of sales outlets and automatic teller machines on the one hand, and a large number of card providers and a large number of payments settlement systems on the other, with a central server which manages and controls the individual transactions, have become established as the typical architecture for cashless payments systems.
Here the fact that data records which contain confidential data strings, such as card or account numbers, also referred to in the following application as PANs (Primary Account Numbers), have to be not only transmitted but also processed and stored, has proved to be a challenge. In particular the PANs stored and being processed on the server must be protected so that they cannot be accessed or seen by third parties in order to prevent abuse of the payments system.
Methods have been developed for tokenising the PANs received in plain text, that is, for replacing these plain text PANs by random tokens uniquely assigned to the PANs, in order to ensure protected processing and storage of data records containing PANs. As the tables with the assignment between the replaced PANs and tokens are stored securely separately from the processing programs, there is no way in which a third party can derive the associated PANs from the data records being processed which are aliased with the aid of the tokens.
In the present context, tokenisation is understood to mean a method for replacing a data string by a substitute string which is also referred to as a token. Indispensable requirements of the tokenisation are the reversibility of the method, that is, each token must be uniquely reassignable to the original data string, and the retention of the format of the tokenisation in order to be able to process further, in particular store, the data record in which an unencrypted data string has been replaced by a token.
One way of replacing security-relevant data strings by tokens is the use of a replacement table which, for each incoming data string, contains a randomly generated token which replaces the unencrypted data string. However, such a replacement table has the disadvantage that the assignment between the data strings and the tokens must be stored somewhere after the replacement of the data string, for this assignment alone allows a data string to be reconstituted from the token when the data record has to be passed to another agency for further processing.
Alternatively, the tokenisation can also be carried out by a bijective mathematical function which is applied to the data string to be encrypted and provides the unique assignment of the unencrypted data string to the token and of the token to the unencrypted data string.
Whereas replacement tables have the disadvantage that they require a large amount of storage capacity and possibly entail specific requirements for synchronised operation of several systems for improved reliability, the generation of tokens with the aid of a mathematical function applied to the data string to be replaced involves not inconsiderable security risks.
Possible attacks on systems which attempt to process data securely with the aid of tokenisation are an attack on the method for replacing the original data string by the tokens or an attack on the reconstitution process which makes it possible to reconstitute the original data strings from the tokens.
Anybody who knows the encrypting function of a tokenisation method in which the token is generated mathematically from the original unencrypted data string can access all the current and all the future tokens generated with this algorithm. In contrast, algorithms which are based on the assignment of the unencrypted data string to a randomly generated token are more secure since, in particular, it is not possible to determine future data string/token pairs from one data string/token pair.